The fromCRDModule prototype duplicated generator.nix's schema walk
(genDefinitions / mapType / genResourceOptions) inside module.nix — two
hand-kept twins of the type/coercion branch logic, the part most likely to
drift (flagged in review).

Extract the walk into walk.nix, parameterized by a `backend` of emit
combinators (types, mkOption, submoduleOf, coerce-attrs-to-list-by-key, ...).
Two backends implement it:
  - backend-text.nix  -> Nix source fragments; generator.nix assembles them
                         into the committable standalone .nix file
  - backend-value.nix -> live values via runtime.nix; module.nix assembles
                         them into a module value

generator.nix and module.nix are now thin assemblers over the one walk; the
branch logic exists in a single place (net -197 lines).

Verified: file generator output byte-identical (argocd store hash unchanged);
fromCRDModule still renders identically to fromCRD (nix run .#crdModuleTest);
moduleTests 42/42; crd2jsonschema 18/18; staticCheck clean.

Remaining (irreducible) duplication: the runtime helper block exists as live
functions in runtime.nix and as inlined source in generator.nix's template.
Committed standalone files can't reference nixidy internals, and live
types/functions can't be serialized back to source — so the two forms must
coexist. The walk (the real divergence risk) is no longer duplicated.

crdObjects { src, crds, kindFilter ? [ ] } returns the raw
CustomResourceDefinition objects from a set of CRD YAML files as values —
the objects counterpart to fromCRD's types. Deployment-agnostic: it hands
back the manifests and lets the caller decide what to do with them (e.g.
apply them to a cluster), rather than baking in an install mechanism.

Reuses fromChartCRD's isWanted filter shape; kindFilter mirrors fromCRD's
(empty = every CRD).

Add the chart counterparts of the src-based accessors:
  - fromChartCRDModule  → resource type module from a chart's CRDs
  - crdObjectsFromChart → raw CustomResourceDefinition manifests from a chart

Both share an internal mkChartCRDsYaml (raw `helm template --include-crds`),
so calling both with identical args templates the chart once. The output is
raw helm YAML parsed directly downstream — no klib.fromHelm/yq-go
re-serialization, avoiding its number-coercion quirks.

kubeVersion is now a first-class, overridable argument across the chart
family (fromChartCRD too), defaulting to nixidy's nixpkgs version. Consumers
templating CRDs for a cluster on a different Kubernetes version can target it
explicitly — previously the version was hardcoded to nixidy's pkgs.

Completes the CRD API matrix: {fromCRD, fromCRDModule, crdObjects} × {src,
chart}. fromChartCRD is unchanged for existing callers (same default).

Expand the accessor test (renamed crdModuleTest -> crdAccessorTest) from
fromCRD<->fromCRDModule equivalence to the full value-accessor surface:

- fromChartCRDModule renders identically to fromCRDModule for the same CRD
  (a local helm chart shipping the CRD in crds/, copied verbatim).
- crdObjects returns the raw CRD manifests; kindFilter narrows (hit + miss).
- crdObjectsFromChart returns the same objects as crdObjects.
- the chart accessors honor kubeVersion: a templated CRD embedding
  .Capabilities.KubeVersion renders v1.31 vs v1.40 observably differently.

Seven checks; the derivation builds iff all pass.

Drop the hand-rolled helm-template derivation in favor of
klib.buildHelmChart, per review. Materialize its single-file output as
$out/crds.yaml via runCommand cp rather than linkFarm: crdObjects reads
crds.yaml at eval time, and a linkFarm symlink would make that read
follow into buildHelmChart's separate output (a store path absent from
the readFile string's context) which pure eval forbids. A real file
keeps the read in-context.

`crds` meant two different things: a list of CRD YAML files (src-based
fromCRD/fromCRDModule/crdObjects) and a kind filter (chart-based
fromChartCRD/fromChartCRDModule/crdObjectsFromChart). Split into two
self-describing names:

  - src-based:   crds -> crdFiles
  - chart-based: crds -> kindFilter  (same role as fromCRD's kindFilter)

Every function keeps `crds` as a deprecated alias (new arg wins; falling
back to `crds` emits a lib.warn pointing at the replacement) via a shared
`renamedArg` helper, so existing callers keep working. The crd2jsonschema
JSON contract is unchanged (still keyed `crds`).

Tests cover both new names and the deprecated alias (9/9).

…r rename

- typed_resources.md: lead the CRD section with the output-shape × source
  matrix; add subsections for fromCRDModule/fromChartCRDModule (module value,
  no generated file) and crdObjects/crdObjectsFromChart (raw manifests);
  document the kubeVersion chart argument; rename crds → crdFiles (src) /
  kindFilter (chart) in all examples with a deprecation note.
- architecture.md: describe the shared walk + text/value backends and the
  six-accessor matrix; update the CRD example args.
- llms.txt: mention the module-value and raw-object accessors.